I'm writing some DXL attribute code and any time the code references itself in any form, DOORS will just disappear.
Example: attribute name = myStatus
if (obj."myStatus" "" == "x") ... poof DOORS be gone. No errors, it just disappears. if(null obj."myStatus") ... poof string s = obj."myStatus" "" ... poof
I've even tried navigating up a link and trying to reference this attribute from the parent, and poof.
I can write DXL code that does not go into a DXL attribute that can read the information from the object attribute without issue, but anytime that code is inserted into the DXL attribute, DOORS disappears. My requirement states that I shall algorithmically determine this status and when a particular calculation achieves a particular value, it shall not be changed or updated again. As such, I need to read what the current value is to ensure that the DXL doesn't inadvertently update the value. My only solution this far is to mirror this attribute with a "hidden" text field that I read, but this requires the code to write to an attribute which causes latency in the updates due requiring a write-lock to actually update the value. Can anybody confirm my findings? Explanations? Better solution? Thanks. MGDMGD - Tue Jul 28 12:10:53 EDT 2015 |
Re: DXL attribute self-reference closes DOORS I believe self reference in a DXL attribute will cause an infinite loop |
Re: DXL attribute self-reference closes DOORS Hi To solve this problem, the funktion attrDXLName exists. string s = obj.attrDXLName; ... no poof Best regards Wolfgang |
Re: DXL attribute self-reference closes DOORS Wolfgang Uhr - Wed Jul 29 02:37:24 EDT 2015 Hi To solve this problem, the funktion attrDXLName exists. string s = obj.attrDXLName; ... no poof Best regards Wolfgang Wolfgang, thanks for your response, but this also closes DOORS, albeit after a pop-up saying it needs to close. |
Re: DXL attribute self-reference closes DOORS MGDMGD - Wed Jul 29 10:37:23 EDT 2015 Wolfgang, thanks for your response, but this also closes DOORS, albeit after a pop-up saying it needs to close. Hi You ar right, sorry this response was to fast. You cannont use this function to check the value. You only can assign a value. obj.attrDXLName = "Some Data"; ... no poof Best regards Wolfgang |
Re: DXL attribute self-reference closes DOORS
Attribute DXL sets the value (using attrDXLName or the attribute name). It cannot query the current value as there is no concept of 'current value' and 'future value'.
The current value constantly updates dynamically according to the code you define in the DXL attribute which can only query other attributes.
|
Re: DXL attribute self-reference closes DOORS ( Have you tried something like ... // just for test obj.attrDXLName = "yes" if ( probeAttr_(obj, attrDXLName) == "yes" ) obj.attrDXLName = "OK" ?? o;) ) |
Re: DXL attribute self-reference closes DOORS Attr-DXL values are not saved in the module; none are yet "calculated" when you open the module. If the obj-attr value has not been set, querying its value causes the attr-DXL to run and calculate the value. If the obj-attr has a value then, when queried, the attr-DXL will not run. If that attr-DXL queries the value then we can presume its value has not been set and the query will try to calculate the value, and you can see how that is an infinite call loop. If you don't grasp the above two paragraphs yet specifically say so; maybe someone can explain it better than me. I don't know why your "poof" is not preceded by some rude "stack overflow" error but that doesn't matter. If I understand your original problem, you want this value to "advance" in state but never "retreat" in state, over the course of the life of the object. You also want the "advance" to occur real time; such as when you modify the state of some linked object. To do that you must have a mechanism for saving the advance state of the object while the module is closed; and attr-DXL won't do that. Yes, having the module open "edit" is the clear choice and save the value in some non-Attr-DXL attribute (presumably enumerated). The sibling attr-DXL would check for and set this enumerated attribute value but never set its own value; if you stick both in a view this will cause the attr-DXL to recalculate continuously. You could have a background batch script run nightly under Admin authority that opens the module Edit and advances the value. Then your attr-DXL could be sensitive to working on a non-edited module. You could plausibly save the obj-attr values in some Configuration file; but I doubt you want that can of worms. You could plausibly have some silly module with a single silly object for each of your requirements, and link from silly-to-real. You could then update the value in the silly object, or even have a silly link-attribute value updated. I prefer the background nightly batch script approach. We can mitigate the need for "real time" update by allowing the attr-DXL to set its own value whenever that value is more advanced than the real value; effectively predicting what the batch script will do later tonight. -Louie |
Re: DXL attribute self-reference closes DOORS llandale - Mon Aug 10 15:33:13 EDT 2015 Attr-DXL values are not saved in the module; none are yet "calculated" when you open the module. If the obj-attr value has not been set, querying its value causes the attr-DXL to run and calculate the value. If the obj-attr has a value then, when queried, the attr-DXL will not run. If that attr-DXL queries the value then we can presume its value has not been set and the query will try to calculate the value, and you can see how that is an infinite call loop. If you don't grasp the above two paragraphs yet specifically say so; maybe someone can explain it better than me. I don't know why your "poof" is not preceded by some rude "stack overflow" error but that doesn't matter. If I understand your original problem, you want this value to "advance" in state but never "retreat" in state, over the course of the life of the object. You also want the "advance" to occur real time; such as when you modify the state of some linked object. To do that you must have a mechanism for saving the advance state of the object while the module is closed; and attr-DXL won't do that. Yes, having the module open "edit" is the clear choice and save the value in some non-Attr-DXL attribute (presumably enumerated). The sibling attr-DXL would check for and set this enumerated attribute value but never set its own value; if you stick both in a view this will cause the attr-DXL to recalculate continuously. You could have a background batch script run nightly under Admin authority that opens the module Edit and advances the value. Then your attr-DXL could be sensitive to working on a non-edited module. You could plausibly save the obj-attr values in some Configuration file; but I doubt you want that can of worms. You could plausibly have some silly module with a single silly object for each of your requirements, and link from silly-to-real. You could then update the value in the silly object, or even have a silly link-attribute value updated. I prefer the background nightly batch script approach. We can mitigate the need for "real time" update by allowing the attr-DXL to set its own value whenever that value is more advanced than the real value; effectively predicting what the batch script will do later tonight. -Louie Or a background enumerated and a displayed attr-DXL. The Attr-DXL calculates the current state and displays,it; never allowing it to be less advanced than the background enumerated. If the user wants an real-time update they can "Refresh DXL Attributes", or close and re-open the module. |
Re: DXL attribute self-reference closes DOORS llandale - Mon Aug 10 15:33:13 EDT 2015 Attr-DXL values are not saved in the module; none are yet "calculated" when you open the module. If the obj-attr value has not been set, querying its value causes the attr-DXL to run and calculate the value. If the obj-attr has a value then, when queried, the attr-DXL will not run. If that attr-DXL queries the value then we can presume its value has not been set and the query will try to calculate the value, and you can see how that is an infinite call loop. If you don't grasp the above two paragraphs yet specifically say so; maybe someone can explain it better than me. I don't know why your "poof" is not preceded by some rude "stack overflow" error but that doesn't matter. If I understand your original problem, you want this value to "advance" in state but never "retreat" in state, over the course of the life of the object. You also want the "advance" to occur real time; such as when you modify the state of some linked object. To do that you must have a mechanism for saving the advance state of the object while the module is closed; and attr-DXL won't do that. Yes, having the module open "edit" is the clear choice and save the value in some non-Attr-DXL attribute (presumably enumerated). The sibling attr-DXL would check for and set this enumerated attribute value but never set its own value; if you stick both in a view this will cause the attr-DXL to recalculate continuously. You could have a background batch script run nightly under Admin authority that opens the module Edit and advances the value. Then your attr-DXL could be sensitive to working on a non-edited module. You could plausibly save the obj-attr values in some Configuration file; but I doubt you want that can of worms. You could plausibly have some silly module with a single silly object for each of your requirements, and link from silly-to-real. You could then update the value in the silly object, or even have a silly link-attribute value updated. I prefer the background nightly batch script approach. We can mitigate the need for "real time" update by allowing the attr-DXL to set its own value whenever that value is more advanced than the real value; effectively predicting what the batch script will do later tonight. -Louie Thank you for your feedback. This is helpful. |
Re: DXL attribute self-reference closes DOORS MGDMGD - Tue Aug 11 09:50:36 EDT 2015 Thank you for your feedback. This is helpful. Or, you can use a trigger on "module open post" event to update a normal attribute.
//Trigger code
/*
Trigger t = current Trigger
if(null m or !isVisible m) halt
Object o
then delete the trigger with this:
|